Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9611/000097_owner-urn-ietf _Thu Nov 7 11:35:09 1996.msg

Internet Message Format | 1997-02-19 | 4KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA29180 for urn-ietf-out; Thu, 7 Nov 1996 11:35:09 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA29175 for <[e-mail]>; Thu, 7 Nov 1996 11:35:07 -0500
Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA22622  (mail destined for [e-mail]); Thu, 7 Nov 96 11:34:12 -0500
Received: from ifi.unizh.ch by josef.ifi.unizh.ch
          id <[e-mail]>; Thu, 7 Nov 1996 17:30:38 +0100
Subject: Re: [URN] I18N does not belong in URNs
To: [e-mail]
Date: Thu, 7 Nov 1996 17:30:37 +0100 (MET)
Cc: [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail]> from "Lewis Girod" at Nov 6, 96 06:48:00 pm
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2326
From: Martin J Duerst <[e-mail]>
Message-Id: <"josef.ifi..250:07.10.96.16.30.39"@ifi.unizh.ch>
Sender: [e-mail]
Precedence: bulk
Reply-To: Martin J Duerst <[e-mail]>
Errors-To: [e-mail]

Lewis Girod wrote:

>   this group seriously would agree to restrict URNs to digits
>   only for this reason, I would understand.
>   But with ASCII as a "restricted" character set, we will definitely
>   get cruftiness, and I see no reason to allow cruftiness for
>   English, but to deny it for most other languages.
>
>One idea we were experimenting with here was to use a subset of ASCII
>that included only numerals, punctuation and consonants, which would
>make most words hard to express (at least in some languages).

There are some languages that use mostly consonants, esp. some
of the Slavic languages. Arabic and Hebrew in principle write only
consonants. But I am less worried about these aspects.

What I am worried about is that we just exclude 5 letters from 26.
This may not be noticed by some people, who happily will use
AEIOU also. We have this now, as for example "~" seems to be
unsafe or excluded, but still is used all the time.

Also, many accronyms contain only consonants (e.g. HTML and HTTP),
and if somebody wants to use words with vowels stripped, it
will unduely give advantages to some and disadvantages to others.
For example, compare mcrsft, ppl, bm, dgtl, hp, sn, and so on.

So just cutting out the vowels is not enough if we want to go
that way; for a small set, my preference would still be for
0123456789#* (phone keys). Of course, my general preference is
for full i18n with UTF-8.


>   The interesting thing is that we already have that, in the current
>   syntax draft. Just call the readable form of it UFNs, and call
>   the encoded form, %HH-escaped, URNs. I have proposed similar
>   names for these things, namely IRNs (internationalized ...).
>
>True, those strings are hard to read but it doesn't solve the problem
>because the URN and the UFN are tightly coupled -- the whole point of
>UFNs is that they are nicknames with a short lifespan.  A UFN should
>be allowed to change over time without ever changing the aliased URN.

I didn't want to stress that the %HH strings are difficult to read.
What I a looking for in UFNs is that they are user friendly, i.e.
easy to understand and type in by somebody e.g. in Japan or so,
and that they are tightly coupled to something else, e.g. URNs
or URLs, so that they can be resolved quickly and deterministically.

Regards,    Martin.